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METHOD AND SYSTEM FOR RESTRAINED BUDGET USE 

The present invention relates generally to methods and apparatuses for managing 
resources in operating systems, and more particularly to a method and apparatus for 
managing resources in an operating system that functions in real-time. 

High volume electronics (HVE) consumer systems, such as digital television sete, 
digitally improved analog television sets and set top boxes (STBs), are typically part of 
product families, which are required to become open and flexible, while remaining cost- 
effective and robust. Such systems have properties that are characteristics of the hard 
real-time domain. 

As openness and flexibility are typical characteristics of software based systems, 
significant parts of the media processing in HVE consumer systems are expected to 
become implemented in software, in addition to the existing software realizations for 
control and services. Component technology is considered to be basic technology for 
open and flexible systems. Note that because HVE consumer systems are typically part 
of product families, component technology is already very important for existing software 
intensive HVE consumer systems; developing such systems using component technology 
significandy reduces the development lead-time and the development cost, amongst 
others benefits. 

Moreover, consumer products are heavily resource constrained. As a 
consequence, the available resources must be used very cost effectively, while preserving 
typical qualities of HVE consumer systems, such as robustness, and meeting stringent 
timing requirements imposed by, for example, high quality digital audio and video 
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processing. Concerning robustness, no one expects, for example, a television set to stall 
with the message "please reboot the system." The notion of resource budgets (or 
reservations) is a proven concept to provide temporal isolation between applications. 

Currently work exists with a system implementing budgets on top of a 
commercial-off-the-shelf (COTS) real-time operating system (RTOS) providing fixed- 
priority preemptive scheduling (FPPS). 

U.S. Patent No. 5,838,968 discloses a system and method for dynamic resource 
management across tasks in real-time operating systems. The system and method manage 
an arbitrary set of system resources and globally optimize resource allocation across 
system tasks in a dynamic fashion, according to a system specified performance model. 

U.S. Patent Application Publication No. US 2002/0138679 Al discloses a system 
and melhod for priority inheritance, in which the method tests a priority inheritance 
variable associated with a task, and lowers the current priority of a task when testing the 
priority inheritance variable indicates that the task holds no resources that are involved in 
a priority inheritance. 

U.S. Patent Application Publication No. US 2002/0133530 Al discloses a method 
for resource control that includes resource stealing by a higher priority task from a lower 
priority tasks. 

In some cases, budget allocations are less than ideal, which can lead to inflexible 
operation or improper use of resources. 

The present invention is therefore directed to the problem of developing a method 
and apparatus for improving resource use in reservation-based scheduling in real-time 
operating systems as well as other similar applications. 
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The present invention solves these and other problems by providing a method for 
controlling an operating system that combines the concepts of multiple task prioritization, 
resource budgeting, resource consumption prediction, and conditional budget allocation. 
In this combination, a budget margin is allocated to a higher priority task, to be used in 
case its budget is not enough, whereas a conditional budget margin is conditionally 
allocated to a designated lower priority task in addition to its budget. The higher priority 
task monitors its budget use and if the higher priority task determines its budget margin is 
unnecessary, the lower priority task is allowed to use its conditional budget margin. 

According to one aspect of the present invention, a higher priority task (eg. , a 
More Important Task) voluntarily restraints its budget usage to a budget without margin, 
and then subsequently explicitly decides to use the margin when needed. 

According to another aspect of the present invention, the higher priority task 
informs an Allocation Mechanism about the decision, and a lower priority task (eg., a 
Less Important Task) is informed as well, either directly or indirectly. This enables the 
Allocation Mechanism or a scheduler to provide this unused budget margin to the lower 
priority task, at least until the higher priority task subsequently determines that it needs 
this budget margin. 

Other aspects of the present invention will become ap|5Srent to those of skill in the 
art upon a review of die detailed description in light of the following drawings. 

FIG 1 depicts a task manager for controlling multiple tasks by assignment of 
relative priorities to the tasks. 

FIG 2 depicts an allocation mechanism for controlling multiple tasks by allocation 
of resources to the various tasks. 
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FIG 3 depicts a scheduler for controlling multiple tasks by granting resources to 
the various tasks in accordance with their reservations. 

FIG 4 depicts a more important task operating within its allocation of resources. 

FIG 5 depicts the interaction of the various elements of FIGs 1-4 and 19. 
5 FIG 6 depicts an exemplary embodiment of an operating system according to one 

aspect of the present invention. 

FIG 7 depicts an exemplary embodiment of an allocation mechanism according to 
another aspect of the present invention. 

FIG 8 depicts an exemplary embodiment of a scheduler according to yet another 
1 0 aspect of the present invention. 

FIG 9 depicts an exemplary embodiment of a more important task operating 
according to still another aspect of the present invention. 

FIG 10 depicts an exemplary embodiment of a less important task operating 
according to yet another aspect of the present invention. 
15 1 1 depicts the interaction of the various elements of FIGs 1 and 7-10 

according to still another aspect of the present invention. 

FIG 12 depicts another exemplary embodiment of an allocation mechanism 
according to yet another aspect of the present invention. 

FIG 13 depicts an exemplary embodiment of a conditional budget monitor 
20 according to still another aspect of the present invention. 

FIG 14 depicts another exemplary embodiment of a scheduler according to yet 
another aspect of the present invention. 
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FIG 15 depicts an additional exemplary embodiment of a more important task 
operating according to still another aspect of the present invention. 

FIG 16 depicts an additional exemplary embodiment of a more important task 
operating according to yet another aspect of the present invention. 
5 FIG 17 depicts the interaction of the various elements of FIGs 1 and 12-16 

according to still another aspect of the present invention. 

FIG 18 depicts a time line of the interactions of the various processes according to 
yet another aspect of the present invention. 

FIG 19 depicts a less important task operating within its allocation of resources. 
10 FIG 20 depicts an exemplary embodiment of a synchronous process execution. 

FIGs 21-22 depict an exemplary embodiment of an asynchronous process 
execution. 

FIGs 23-24 depict another exemplary embodiment of an asynchronous process 
execution. 

15 It is worthy to note that any reference herein to "one embodiment" or "an 

embodiment* ' means that a particular feature, structure, or characteristic described in 
connection with the embodiment is included in at least one embodiment of the invention. 
The appearances of the phrase "in one embodiment" in various places in the specification 
are not necessarily all referring to the same embodiment. 

20 Details regarding the assignment of priorities, designations of MITs and LITs, and 

the determination of budgets and other related information could be found in U.S. Patent 
Application Serial Nos. 10/169,346 and 10/294,530, both of which have been 
incorporated by reference as if repeated herein in their entirety including the drawings. It 
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should be noted that in these patent applications, the notion of priority is being used in the 
meaning of Operating System priority, and not in the meaning of relative importance. In 
the scheduling algorithm used, the former priorities are in general allocated according to 
(he budget periods* Sometimes it is convenient to unify the OS priorities and the relative 
5 importance, especially if all tasks have the same budget period. However, unifying the 
two priority types is not always applicable. Moreover, OS priorities may be dynamic, e.g. 
in an OS that uses earliest deadline first scheduling. In that case the two priority types 
cannot be unified. Therefore, the following shall focus on the aspects relating to the 
interaction of the MIT, the LIT, the Allocation Mechanism and the scheduler to make use 
10 of the Guaranteed Budget Margin when not being used by the MIT. FIGs 1 -5 depict the 
various elements to which the inventions set forth herein are applicable. 

FIG 1 shows an exemplary embodiment of a task manager process 10 for 
controlling two tasks in a real-time operating system. As used herein, task manager and 
' application manager (see description of FIG 5) may be used synonymously. A realistic 
15 task manager includes a cycle. This means that there exists a condition element (eg., 
continue? - element 11) right after start. If yes, the process 10 performs elements 12 
through 16 and loops back to the condition element 1 1 (while loop). If no, process 10 
stops. According to process 10, one task is assigned to be a More Important Task 12, 
while a second task is assigned to be a Less Important Task 1 3. There may be more than 
20 one More Important - Less Important task pairs at any point in time, but the description 
herein refers to a single pair. What is described herein could be applicable to multiple 
pairs though. At this point in the process, the task manager (or some equivalent) becomes 
inactive (with respect to these two tasks) 14. Subsequently, the first task is de-assigned 



US030451 



7 



from being the More Important Task 1 5 and the second task is de-assigned from being the - 
Less Important Task 16, and the process 10 ends. 

Turning to FIG 2, shown therein is an exemplary embodiment of an allocation 
mechanism process 20 (kg., when active during element 14 of FIG 1), with respect to the 

5 same two tasks. The allocation mechanism allocates a Guaranteed Budget Margin 
(GBM) to the MIT along with a More Important Guaranteed Budget (MIGB) 21 . The 
allocation mechanism then allocates a Less Important Guaranteed Budget (LIGB), and 
conditionally allocates a Conditionally Guaranteed Budget Margin (CGBM), to the LIT 
22. The allocation mechanism then sends a reservation command according to the 

10 allocations made 23. Next, the allocation mechanism does nothing until triggered by 
some event 24. If the event indicates to continue at decision element 25, the 
determination is made that the budgets are not adequate 26, and the allocation mechanism 
process 20, returns to element 21; otherwise, the MIT and LIT roles have expired 27, and 
the process ends. 

1 5 It should be noted that in FIG 2 (as well as FIGs 7 and 12 discussed infra) it is 

assumed that the budgets are dynamically adjustable. The methods set forth herein also 
operate when budgets are NOT dynamically adjustable. In this case, FIG 2 (and FIGs 7 
and 12, as well) would become much simpler because the allocation is done only once. In 
this case, elements 24, 25, 26 and 27 (and their counterparts in FIGs 7 and 12) are not 

20 required. 

In the embodiments herein, we assume that the allocated budgets will be 
replenished periodically, and that the periods and start times are determined by the task. 
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Only the periodic budget is determined by the allocation mechanism. The use of such a 
periodic budget is as follows: 

If task Y receives periodic budget B, with period T, and start time to, then at every 
instant to + n-T, with n > 0, the budget of Y is replenished to B units of time. Y is 
5 guaranteed to receive B units of time between to + n-T and to + (n+l)-T, for n £0, if and 
only if it is able to consume these time units during that period. If it does not have enough 
work to consume the time units in the given period, the unused time is lost at to +(n+l) T. 

Note that a periodic budget is always related to a fractional budget (F), where F = 
B/T, and that the sum of all allocated fractional budgets must be smaller than or equal to 
10 1 . The embodiments herein do not exclusively apply for periodic budgets. In principle, 
the embodiments herein can be applied to all fractional budgets. The embodiments herein 
also do not exclusively apply to processors, CPUs, or operating systems; rather the 
embodiments can also be applied to other temporal resources (e.g. , transportation 
bandwidth). 

15 Turning to FIG 3, shown therein is an exemplary embodiment of a scheduler 

process 30. The scheduler process includes a cycle very similar to the cycle of the 
allocation manager, i.e., the scheduler process includes an event 36 that leads to 
evaluating a condition element (continue?). If yes, there will be a new command from the 
allocation manager, and the scheduler cycles back to element 3 1. If no, the scheduler 

20 stops. Note that when the scheduler loops back, the scheduling algorithm 30 keeps 

running, which is indicated in FIG 3 by element 37, which states: "Start the scheduling 
mechanism" (even when there are no tasks to schedule yet). 
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The scheduling process begins by accepting reservation commands from the 
allocation mechanism for the MIT and the LIT 3 1 . The scheduler grants the MIGB and 
the GBM to the MIT, and thereby allows the scheduling mechanism to start providing 
them on a periodic basis, with a period that is typical for the MIT 32. The scheduler also 
5 grants the LIGB to the LIT and thereby allows the scheduling mechanism to start 
providing it on a periodic basis, with a period that is typical for the LIT 33. The 
scheduler conditionally grants the CGB to the LIT and thereby allows the scheduling 

mechanism to start providing it on a periodic basis, with a period that is typical for the 

> 

LIT 34. The scheduling mechanism continues to run according to the current settings of 
10 the scheduling algorithm 35. In this way, the scheduling mechanism provides the granted 

budgets to the tasks. If an external event occurs 36, the scheduler reaches a condition 37. 

If the scheduler process 30 continues, the scheduler process loops back to element 31; 

otherwise the scheduling activity stops, and the scheduler terminates. 

The "grant X to Y" is intended to mean "set the scheduling parameters in such a 
15 way that X is guaranteed to receive Y". In contrast, "conditionally grants" means that, for 

example, the LIT "inherits" unused budget from MIT. The conditional provision is 

implicit; if the MIT leaves its full GBM unused, then the LIT gets its full CGBM. 
Turning to FIG 4, shown therein is an exemplary emUSdiment of a More 

Important Process interaction based on the embodiments in FIGs 1-3. The MIT process 
20 begins using its MIGB and GBM 4 1 . At some point, the MIT may no longer require the 

GBM 42. Thus, the MIT begins using only the MIGB 43. At decision point 44, the MIT 

continues or not. If the MIT continues, at some point the MIT may require the GBM 45. 
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Thus, the MIT begins using the MIGB and the GBM 46. At decision point 47, the MIT 
process ends or continues at element 42. 

Turning to FIG 19, shown therein is an exemplary embodiment of a Less 
Important Process 400 interaction based on the embodiments in FIGs 1-3. The LIT 

5 process begins using its LIGB 401 . At some point, the CGBM becomes available 402. 
Thus, the LIT begins using the LIGB and the CGBM 4a3. At decision point 404, the LIT 
continues or not. If the LIT continues, at some point the CGBM will no longer be 
available 405. Thus, the LIT begins using the LIGB only 406. At decision point 407, the 
LIT process ends or continues at element 402. 

10 Turning to FIG 5, shown therein is an exemplary embodiment 50 of the 

interaction of the elements of FIGs 1-4 and 19. An application manager 51 assigns and 
. de-assigns the MIT role to a given task (elements 1 1 and 14 of FIG 1). The application 
manager 51 also assigns and de-assigns the LET role to another given task (elements 12 
and 15). The application manager 51 then becomes inactive while the allocation 

15 mechanism 52 becomes active (element 13). When the MIT and LIT roles expire 
(element 26 of FIG 2), the application manager 51 becomes active again, while the 
allocation mechanism 52 becomes inactive. The allocation mechanism 52 allocates the 
MIGB and the GBM to the MIT (element 21 of FIG 2) and the LIGB and the CGBM to 
the LIT (element 22 of FIG 2). The allocation mechanism 52 sends the reservation to the 

20 scheduler 55 (element 23 of FIG 2), which activates element 3 1 of FIG 3, in which the 
scheduler 55 accepts reservation commands for the LIT and the MIT from the allocation 
mechanism (element 31), grants the MIGB and GBM to the MTT 53 and the scheduling 
mechanism starts providing them on a periodic basis to the MIT (element 32). The 



US030451 



scheduler 55 also grants the LIGB to the LIT 54 and begins providing this on a periodic 
basis to the LIT (element 33). The scheduler 55 also conditionally grants the CGBM to 
the LIT 54, and starts providing this to the LIT 54 on a conditional basis (element 34). 
The scheduler 55 then runs in accordance with a scheduling algorithm (element 35). 
5 During this- time, the MIT at some point does not require the GBM 42, and the CGBM 
becomes available to the LIT 400. At some other point, the MIT requires the GBM again 
45, and the CGBM is no longer available to the LIT 4a5. This sequence of 42-4a2 
followed by 45-4a5 can be repeated one or more times. In the case of zero repetitions, 
which is realistic, FIGs 4 and 19 would need to be modified, with the condition element 

10 47 between elements 41 and 42 rather than between elements 46 and 42, thereby implying 
a while loop instead of an until loop. 

A More Important Task (FIG 4) can have two types of behavior. The first type of 
behavior, known as synchronous behavior, occurs when the task works in synchrony with 
the budget consumption (*.&, the task starts when the budget is replenished and completes 

15 its work within the budget period). 

Turning to Figure 20, shown therein is an exemplary embodiment of a timeline 
200 for a synchronous task. At the start of a first budget period 201, with replenished 
MIGB and GBM, the corresponding execution of the task (eg., processing of a first video 
frame) starts 202. Some time later, the task execution completes 203. The MIGB is not 

20 completely used up, and the GBM is completely unused. Some time later, the first period 
terminates 204. 

At the start of a second budget period 205, with replenished MIGB and GBM, the 
corresponding execution of the task (e.g., processing of the first video frame) starts 206. 
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Some time later, the MIGB is completely depleted 207. Still some time later, the task 
execution completes 208. The GBM is not completely used up. Yet some time later, the 
second budget period terminates 209. 

The timeline shows two exemplary budget periods. In the first budget period, from 
5 201 to 204, the task execution completes within the MIGB. In the second budget period 
from 205 to 209, task execution also requires some part of the GBM. 

The second type of behavior, known as asynchronous behavior, occurs when the 
task does not work in synchrony with its budget. In asynchronous behavior, a task may 
work-ahead or lag-behind its budget consumption. Asynchronous behavior is often used 

10 to smoothen out loads. 

Turning to FIG 21, shown therein is an exemplary embodiment of a timeline 210 
for an asynchronous task. At the start of a first budget period 211, with replenished MIGB 
and GBM, the first execution of the task (eg:, processing of the first video frame) starts 
212. Some time later, the MIGB is fully depleted 213. Still some time later, the first task 

15 execution completes in time, while the GBM is not completely used up 214. The task 
immediately starts its second execution 215. Still some time later, the GBM is also 
depleted 216, and the second task execution is suspended 217. Yet some time later, the 
period terminates 21 8. During this first budget period, one task completion has taken 
place. In other words, the task has completed one unit of work. 

20 At the start of a second budget period 22 1 , with replenished MIGB and GBM, the 

second task execution, suspended in the previous period, is resumed 222. Some time later, 
the MIGB is completely depleted 223. Still some time later, the GBM is also depleted 
224, and the second task execution is again suspended 225. Some time later, the period 
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terminates 226. During this second period, no task completion has taken place. The 
second task execution will be late. 

Turning to FIG 23, shown therein is another exemplary embodiment of a timeline 
230 for an asynchronous task. At the start of the first budget period 23 1 , with replenished 

5 MIGB and GBM, the first task execution starts 232. Some time later, the first task 

execution completes in time 233. The task immediately starts its second execution 234. 
Still some time later, while the MIGB is completely used up 235, and after that the GBM 
is also depleted 236. At this point the second task execution is suspended 237. Some time 
later, the period terminates 238. During this first period one task execution is completed. 

10 At the start of a second budget period 239, with replenished MIGB and GBM, the 

task execution suspended in the previous period is resumed 240. Some time later, the 
second task execution completes 241, and the third task execution gets started 242. Still 
some time later, the MIGB is completely depleted 243. Still some time later, the third task 
execution completes early 244. The fourth task execution starts 245/ Some time later, the 

1 5 GBM is also depleted 246, and hence the fourth task execution is suspended 247. Still 
some time later, the period terminates 248. In this second period, two task executions 
completed. 

The two timelines 210 and 230 show that the situation can be very different 
depending on the budget period, but that a short task execution does not necessarily free 
20 up the GBM when the task executes asynchronously. 

According to one aspect of the present invention, the provision of a Conditionally 
Guaranteed Budget Margin (e.g., an amount of resources allocated to a task that is above 
and beyond the amount budgeted for the task, which is not necessarily guaranteed to be 



US030451 



14 



available for every budget period, but rather its availability is dependent on some other 
factor) is implicit. In contrast, the allocation is always explicit. The per-period provision 
is implicit. 

According to another aspect of the present invention, if the More Important Task 

5 (MIT) does not use its Guaranteed Budget Margin, the Less Important Task receives the 
MTTs Guaranteed Budget Margin. This can lead to the following problem. Even though 
the More Important Guaranteed Budget (MIGB) is on average sufficient for the MIT, the 
budget consumption of the MIT may still exceed the More Important Guaranteed Budget 
during certain budget periods (such as during transient high loads for synchronous tasks, 

10 207-208, and when a next task execution is ready to start for asynchronous tasks 213 and 
243). In these periods, the MET will use part of its Guaranteed Budget Margin, and the 
LIT will receive less than its Conditionally Guaranteed Budget Margin. 

There is a second related problem, which occurs with asynchronous processing 
only. An asynchronous task is unable to restrain its budget use, precisely because it is 

15. asynchronous. 

Load Estimation and load adjustment 

MTTs with synchronous behavior are sometimes able to estimate the amount of 
work to be done before doing the work, and subsequently process the data in such a way 
at such a quality level) that the work is completed before the budget is fully 

20 depleted. MITs with asynchronous behavior typically measure the amount of progress 
made, and subsequently adjust the quality level of processing data to avoid missing 
deadlines. In both cases, the MIT keeps track of how well the budgets fit its needs. This 
capability can be used to request the allocation manager to adjust the budgets. 
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In general, to the above elements and functions, the present invention employs 
inter alia conditionally guaranteed budget margins (CGBMs) associated with tasks 
assigned relative importance. 

5 According to one aspect of the present invention, the MIT and the LIT are 

explicitly informed of their budgets. Thus, the MET can therefore restrain its budget 
usage to the budget without margin. 

According to another aspect of the present invention a More Important Task 
(MIT) voluntarily restraints its budget usage to a budget without margin, and explicitly 

1 0 decides to use or not use the margin when needed. The More Important Task informs its 
environment (e.g. , the allocation mechanism or the scheduler or a budget monitor) about 
the decision. The Less Important Task (LIT) gets informed that it will or will not receive 
its CGBM (either directly from the MIT or indirectly through another agent). This 
decision is not necessarily intended to be made on a per-budget basis, but usually much 

1 5 less frequently. Moreover, the decision is not always made at a budget boundary either. 
This decision is typically made at the start of a new task execution. Restraining the budget 
use is not sufficient An asynchronous task is unable to stop executing when the MIGB is 
depleted, and the GBM is still available. An asynchronous tari* is unable to detect this 
transition. Therefore, a second aspect of the present invention is that while the MTT 

20 initiates the budget restriction, the scheduler actually performs it by constraining the MIT 
to its MIGB. 

Turning to FIG 6, shown therein is an exemplary embodiment of a method 60 for 
controlling multiple tasks in a real-time operating system according to one aspect of the 
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present invention. In the method 60, a first task is assigned to be a More Important Task 
(element 61). The prioritization of this task enables the system to allocate resources or 
other limited availability items, such as processor access, memory, user interfaces, etc. 

A second task is assigned to be a Less Important Task (element 62). The second 
5 task is merely a task that is considered to be a lower priority (i.e. lower relative 

importance) than the first task, however, the second task may also be a higher priority 
(f.e., higher relative importance) task than some other task or tasks. 

A Guaranteed Budget Margin is then allocated to the More Important Task along 
with a More Important Guaranteed Budget, and The MIT is informed of that allocation 
10 (element 63). A More Important Guaranteed Budget is the amount of resources or other 
limited availability items set aside for use by the first task. The Guaranteed Budget 
Margin is the amount of resources or other limited availability items set aside for use by 
the first task above and beyond the More Important Guaranteed Budget in case needed by 
the first task. 

15 A Less Important Guaranteed Budget is also allocated to the Less Important Task 

and the LIT is informed of that allocation (element 64). The Less Important Guaranteed 
Budget is the amount of resources or other limited availability items set aside for use by 
the second lower priority task. In addition, a Conditionally Guaranteed Budget Margin is 
conditionally allocated to the second task, which is informed of that allocation (element 

20 65). 

At some point during execution, the higher priority or More Important Task may 
determine that the More Important Task no longer requires the Guaranteed Budget 
Margin in the subsequent budget periods (element 66). This can occur because the higher 
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priority task monitors its usage of budget items, and can predict its needs during a given 
budget cycle. A message is then sent that the More Important Task does not require its 
Guaranteed Budget Margin (element 67). This message can originate with the MIT or 
from some other process, such as a scheduler or a conditional budget monitor. However, 
the only one that can send this message is the one that detects that the GBM is no longer 
needed. The most likely candidate for sending this message is the MIT. In case of a 
synchronous MIT, it could be the scheduler. In the embodiments presented here, the MIT 
is the one that detects the fact and sends the message. If another party does this, the MIT 
has to be informed as well. 

If the higher priority or More Important Task or some other task indicates that the 
MIT does not require the Guaranteed Budget Margin, the conditionally allocated 
Conditionally Guaranteed Budget Margin can then be provided to the Less Important 
Task (element 68). The Conditionally Guaranteed Budget Margin is the amount of 
resources or other limited availability items set aside for use by the second task above and 
beyond the Less Important Guaranteed Budget in case needed by the second task, but 
which amount is only provided when not needed elsewhere, such as by the higher priority 
or More Important Task. 

Once the message is sent, it is important that the More Important Task really does 
not use its GBM, in whole or in part, during all budget cycles, in order to guarantee the 
CGBM to the second task in every budget cycle, until the CGBM is explicitly withdrawn. 

At some other point during execution, the higher priority or More Important Task 
may determine that the More Important Task again requires the Guaranteed Budget 
Margin in the subsequent budget cycles (element 69). A message is then sent that the 
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More Important Task does requite its Guaranteed Budget Margin (element 691). If the 
higher priority or More Important Task indicates that it does require its Guaranteed 
Budget Margin, the conditionally allocated Conditionally Guaranteed Budget Margin can 
no longer be provided to the Less Important Task, hence the CGBM is removed from the 

5 LIT and the GBM is provided to the MIT and the MIT and LIT are informed of these 
allocations (element 692). This process of requiring and not requiring the GBM can be 
repeated several times, as indicated by the loop. 

In the embodiments herein, the control algorithm local to the higher priority task 
(e.g., the MIT) is extended in such a way that the control algorithm: 

10 . (a) restrains the MTT*s budget usage voluntarily, if appropriate (part of element 66 

in FIG 6); 

(b) signals that the Guaranteed Budget Margin (GBM) is required from now on, or 
that the Guaranteed Budget Margin is no longer required from now on (see element 67, 
FIG 6). As used herein, the budget of the higher priority task relates to the amount of 

15 resources or other limited availability items set aside for use by the higher priority task. 
Also, as used herein, the Guaranteed Budget Margin refers to the budgeted amount of 
resources (or other limited availability items) above that already allocated to the higher 
priority task, which is set aside for the higher priority task. 

An MIT with synchronous behavior will be able to restrain itself during every 

20 budget period so that the Guaranteed Budget Margin is automatically provided to the 
lower priority task (e.g., the Less Important Task) (see elements 201-204, FIG 20). An 
MTT with asynchronous behavior cannot do so precisely because its behavior is 
asynchronous with respect to the budget period (as shown in FIGs 21-24). Without 
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explicit help of the scheduler, an asynchronous MIT will keep consuming its budget (e.g> t 
the More Important Guaranteed Budget) along with its budget margin (e.g., the 
Guaranteed Budget Margin) until the asynchronous MIT blocks for lack of input, being 
increasingly ahead with respect to the budget period, as indicated in FIGs 21-22 and 23- 
5 24. In case of an asynchronous MTT (see FIGs 21-24), which is the more general case, a 
second aspect of the invention is therefore required to ensure the desired budget transfer 
in two directions. 

In case the tasks can operate asynchronously, at run time, with the modified 
control algorithm in place, the following, modified budget allocation protocol ensures the 
10 desired budget transfer in two directions. 

A: When the budgets are assigned by the allocation mechanism: 

1 . The allocation mechanism explicitly informs the MIT about its More Important 
Guaranteed Budget and Guaranteed Budget Margin (see element 63, FIG 6); 

2. The allocation mechanism explicitly informs the Less Important Task about its 
1 5 Less Important Guaranteed Budget and Conditionally Guaranteed Budget Margin (see 

element 64, FIG 6); 

3. The scheduler provides the More Important Guaranteed Budget + Guaranteed 
Budget Margin to the MIT at the first possible occasion (see element 63, FIG 6); 

4. The scheduler provides the Less Important Guaranteed Budget to the LIT at the 
20 first possible occasion (see element 68, FIG 6). 

B: When the MIT does not require its budget margin: 

1. At some point during execution, the MIT observes that it can do its job with its 
More Important Guaranteed Budget only (see element 66, FIG 6); 
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2. The MIT explicitly informs the scheduler that it does not require its 
Guaranteed Budget Margin (see element 67, FIG 6); 

3. The scheduler stops providing the Guaranteed Budget Margin to the MIT at the 
first possible occasion (part of element 67, FIG 6); 

5 4. The scheduler starts providing the Conditionally Guaranteed Budget Margin to 

the LIT at the first possible occasion, which may or may not be instantaneous, depending 
on the application (see element 68); 

5. The scheduler informs the LIT of this additional budget provision (element 

68). 

10 

C: When MIT requires its budget margin again: 

1 . At some point during execution, the MIT observes that it requires its 
Guaranteed Budget Margin as well (element 69); 

2. The MIT explicitly informs the scheduler that it does require its Guaranteed 
1 5 Budget Margin (element 69 1 ); 

3. The scheduler informs the LIT that Conditionally Guaranteed Budget Margin 
will be withdrawn (element 692); 

4. The scheduler stops providing the Conditionally Guaranteed Budget Margin to 
the LIT at the first possible occasion (part of element 692); 

20 5. The scheduler starts providing the Guaranteed Budget Margin to the MTT at the 

first possible occasion (part of element 692). 
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Note that the LIT is informed of a budget decrease before the decrease takes 
place. The LIT is informed of a budget increase after the increase has taken place. The 
LIT cannot influence the change in any way. 

FIG 1 1 shows an exemplary embodiment of the roles and the interactions of the 
5 various processes described in FIGs 7-10. A first task 1 14 has a first priority level, which 
first task 1 14 is called a higher priority task or a More Important Task. This higher 
priority task 1 14 can include either a task external to the operating system 1 10 or internal 
to the operating system 110. 

A second task 115 has a second priority level lower than the first priority level. 
10 This lower priority task (or Less Important Task) 115 can include either a task external to 
die operating system 1 10 or internal to the operating system 110. Moreover, the second 
task 1 15 is merely lower in priority than the first task 1 14, but could even be the second 
most important task to be executed. In these two paragraphs all priorities are relative 
importance. 

15 An allocation mechanism 1 1 2 is included to allocate budgets of resources among 

the various tasks 1 14, 1 15 to be performed by the operating system 110. According to 
one aspect of the present invention, the allocation mechanism 1 12 explicitly informs the 
first task 1 14 about a More Important Guaranteed Budget anr^i Guaranteed Budget 
Margin. The More Important Guaranteed Budget is the amount of resources or other 

20 limited availability items set aside for use by the first task 1 14. The Guaranteed Budget 
Margin is the amount of resources or other limited availability items set aside for use by 
the first task 1 14 above and beyond die More Important Guaranteed Budget in case 
needed by the first task 1 14. The allocation mechanism 1 12 also explicitly informs the 
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second task 115 about a Less Important Guaranteed Budget and a Conditionally 
Guaranteed Budget Margin. The Less Important Guaranteed Budget is the amount of 
resources or other limited availability items set aside for use by the second or lower 
priority task 115. 

5 A scheduler 113 controls provisioning of the budgeted amounts of resources to the 

various tasks 1 14, 1 15 to be performed by the operating system 110, including the first 
task 114 and the second task 115. The scheduler 113 provides the More Important 
Guaranteed Budget plus the Guaranteed Budget Margin to the first task 1 14 at a first 
possible occasion. The scheduler also provides the Less Important Guaranteed Budget to 

1 0 the second task 1 1 5 at a first possible occasion. 

If the first task 1 14 determines at some point during execution that the first task 
114 can execute properly with the More Important Guaranteed Budget only, the first task 
1 14 explicitly informs the scheduler 113 that the first task 114 does not require its 
Guaranteed Budget Margin. In this case, the scheduler 113 stops providing the 

1 5 Guaranteed Budget Margin to the first task 1 14 at a first possible occasion and starts 
providing the Conditionally Guaranteed Budget Margin to the second task 1 15 at a first 

possible occasion. After this, the scheduler 112 informs the second task 115 of the 

« 

granting of the Conditionally Guaranteed Budget Margin. 

The Conditionally Guaranteed Budget Margin is the amount of resources or other 
20 limited availability items set aside for use by the second task 115 above and beyond the 
Less Important Guaranteed Budget in case needed by the second task 115, but which 
amount is only provided when not needed elsewhere, such as by the higher priority or 
More Important Task 1 14. 
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Subsequently, the first task 114 may determine at some point during execution 
that the first task 114 requires the Guaranteed Budget Margin as well, in which case the 
first task 1 14 explicitly informs the scheduler 1 13 that the first task 1 14 does require its 
Guaranteed Budget Margin. The scheduler 113 then informs the second task 115 that the 

5 Conditionally Guaranteed Budget Margin will be withdrawn, the scheduler 1 1 3 stops 
providing the Conditionally Guaranteed Budget Margin to the second task 1 13 at a first 
possible occasion and the scheduler 113 starts providing the Guaranteed Budget Margin 
to the first task 1 14 at a first possible occasion. 

An application manager 111 assigns and de-assigns the MIT role to a given task 

10 (elements 1 1 and 14 of FIG 1). The application manager also assigns and de-assigns the 
LIT role to another given task (elements 12 and 15). The application manager 1 1 1 then 
becomes inactive while the allocation mechanism 1 12 becomes active (element 13 of FIG 
1). When the MIT and LIT roles expire (element 26 of FIG 2), the application manager 
111 becomes active again, while the allocation mechanism 1 12 becomes inactive. The 

1 5 allocation mechanism 1 12 allocates the MIGB and the GBM to the MIT (element 71 of 
FIG 7) and explicitly informs the MIT of these allocations (element 72). The allocation 
mechanism 1 12 also allocates the LIGB and the CGBM to the LIT (element 73 of FIG 7) 
and explicitly informs the LIT of these allocations (element 74 of FIG 7). The allocation 
mechanism 112 sends the reservation to the scheduler 113 (element 75 of FIG 7), which 

20 activates the scheduler process 80 of FIG 8, which executes to completion. The scheduler 
113 accepts reservation commands for the LIT and the MIT from the allocation 
mechanism (element 81); grants the MIGB and GBM to the MIT; and also grants the 
LIGB to the LIT (element 82). The scheduler then runs in accordance with a scheduling 
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algorithm (element 83). The scheduler 113 receives a message from the MIT that the 
MIT no longer requires the GBM (element 85). The scheduler then grants only the MIGB 
to the MTT (element 86), informs the LIT of the budget increase (element 87), and grants 
the LIGB and the CGBM to the LIT (element 88). The scheduler 1 13 may subsequently 
5 receive a message from the MIT that the MIT now requires its GBM (element 81 1), in 
which case the scheduler 1 13 informs the LIT of the budget decrease (element 812). 

Turning to FIG 7, shown therein is an exemplary embodiment of an allocation 
mechanism process 70 according to another aspect of the present invention. The 
allocation mechanism process 70 allocates an MIGB and a GBM to the MIT 71. The 
10 allocation mechanism process 70 also allocates an LIGB and conditionally allocates a 
CGBM to the LIT 72. The allocation mechanism process 70 explicitly informs the MIT 
of its allocations 73. The allocation mechanism process 70 also explicitly informs the 
LIT of its allocations 74. The allocation mechanism process 70 sends a command 
reservation in accordance with the allocations to the MIT and LIT 75. The allocation 
15 mechanism process 70 then waits until it is triggered by some event 76. If the budgets are 
inadequate, the allocation mechanism process returns to element 71 . If the budgets are 
adequate, the MIT and LIT roles expire 78, and the allocation mechanism process 70 
ends. 

FIG 8 shows an exemplary embodiment of a scheduler process 80 according to 
20 another aspect of the present invention. The scheduler process 80 receives the reservation 
commands (as indicated by element 75 of FIG 7) 81, and grants the MIGB and the GBM 
to the MIT and the LIGB to the LIT 82. The scheduling process 80 then executes in 
accordance with the scheduling algorithm 83. At decision point 84, the process 80 
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continues or ends. If the scheduling process 80 continues, at some point the scheduling 
process may receive a message from the MIT indicating the MIT no longer requires its 
GBM 85. The scheduler then grants the MIGB only to the MIT (or removes the GBM 
from the MIT so the MIT has only the MICG) 86. The scheduler process 80 then grants 

5 the LIGB and the CGBM to the LIT (or adds the CGBM to the LTTs resources) 87. The 
scheduler process 80 then informs the LIT of the budget increase 88. The scheduling 
process 80 then executes in accordance with the scheduling algorithm 89. At decision 
point 810, the scheduling process 80 continues or ends. If the scheduling process 80 
continues, at some point the scheduling process 80 may receive a message from the MIT 

1 0 indicating the MIT now requires its GBM 811. The LIT is informed of the budget 
decrease from the scheduler 812 and the scheduling process 80 returns to element 81. 

Turning to FIG 9, shown therein is an exemplary embodiment 90 of the 
interaction of the MIT process with the various other tasks. The MIT process 90 is 
informed by the allocation mechanism process 70 of the MIGB and the GBM 91. The 

15 MIT process 90 begins using the MIGB and the GBM with the scheduler 92. The MIT 
process 90 determines that it does not require the GBM 93, and informs the scheduler 
process 80 that the GBM is not required 94. The MIT process 90 then begins using the 
MIGB only 95. At decision point 96, the MIT process 90 either continues or ends. If the 
MIT process 90 continues, the MIT process 90 may determine that it now requires its 

20 GBM 97. The MIT process 90 informs the scheduler process 80 that it now requires the 
GBM 98, and the MIT process 90 begins using the MIGB and the GBM with the 
scheduler process 99. At decision point 910, the MIT process 90 either ends or returns to 
element 93. 
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Turning to FIG 10, shown therein is an exemplary embodiment 100 of the 
interaction of the LIT process with the various other tasks. The LIT process 100 is 
informed by the allocation mechanism process 70 of the UGB and the CGBM 101. The 
LIT process 100 begins using the LIGB with the scheduler 102. At some point the LIT 
5 process 100 may be informed by the scheduler process 80 that the CGBM is available 
103. The LIT process 100 then begins using the LIGB and the CGBM 104. At decision 
point 105, the LIT process 100 either continues or ends. If the LIT process 100 
continues, the LIT process 100 may be informed that the CGBM is no longer available 
106. The LIT process 100 then begins using only the LIGB with the scheduler 107. At 
10 decision point 108, the LIT process 100 either ends or returns to element 103. 

Turning to FIG 12, shown therein is another exemplary embodiment 120 of the 
allocation mechanism that employs a conditional budget monitor process, according to 
yet another aspect of the present invention. In this embodiment, the allocation 
mechanism is the recipient of the reservation command. The allocation mechanism 
15 process 120 allocates an MIGB and a GBM to the MTT 121. The allocation mechanism 
process 120 also allocates an LIGB and conditionally allocates a CGBM to the LIT 122. 
The allocation mechanism explicitly informs the MIT of its allocations 123. The 
allocation mechanism also explicitly informs the LIT of its allocations 124. The 
allocation mechanism sends a command reservation in accordance with the allocations of 
20 the MIT and LIT 125. The allocation mechanism then waits until it is triggered by some 
event 126. If the budgets are inadequate as determined in decision element 127, the 
allocation mechanism process returns to element 121. If the budgets are adequate, the 
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allocation mechanism process 120 moves to element 128. The MTT and LIT roles expire 
1 28, and the process ends. 

Turning to FIG 13, shown therein is an exemplary embodiment of a Conditional 
Budget Monitor (CBM) process 130 according to another aspect of the present invention. 
5 The CBM receives the reservation commands for the MIT and LIT 1 3 1 , and sends the 
reservations (MIGB + GBM for MTT and LIGB for LIT) to the scheduler 132. The CBM 
then waits for an event At decision point 133, the CBM process 130 continues or ends. 
If the CBM process 130 continues, at some point the CBM process may receive a 
message from the MIT indicating the MIT no longer requires its GBM 134. The CBM 
1 0 then sends a reservation (MIGB for MIT and LIGB + CGBM for LIT) to the scheduler 
135. The CBM then waits for an acknowledgement 136. The CBM then informs the LIT 
of the budget increase 137. The CBM then waits for an event 138. At decision point 139, 
the process 130 either continues or ends. If the process 130 continues, at some point the 
CBM may receive a message from the MIT indicating the MIT now requires its GBM 
15 1310. The CBM informs the LIT of the budget decrease 1311. Preferably, this message 
should reach LIT before the resources are taken away, the success of which will depend 
on many factors, such as distances involved, clock timing, processor speed, etc. 

Turning to FIG 14, shown therein is another exemplar embodiment of a 
scheduling process 140 according to still another aspect of the present invention. The 
20 scheduler will receive reservation commands for one or more tasks 141 (e.g. 9 from the 
CBM of FIG 13). In element 142, the scheduler will then grant the reservation requests 
or modifications from element 141 . The scheduler will then acknowledge the reservation 
command to the sender of the reservation command (e.g., the CBM of FIG 13) 143. The 
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scheduling process then will execute in accordance with the scheduling algorithm 144. 
The process 140 will either continue to element 141 or end in decision element 145. If 
the process 140 continues, it will proceed to element 141. 

Turning to FIG 15, shown therein is an exemplary embodiment 150 of the 
5 interaction of the MIT with the various other tasks from FIGs 1 2-14. The MIT is 

informed of the MIGB and the GBM 91 (e.g., by the Allocation Mechanism) 151 . The 
MIT begins using the MIGB and the GBM with the scheduler 152. The MIT determines 
that it does not require the GBM 153, and sends a message to this effect (e.g., to the 
CBM, which in turn informs the scheduler) 154. The MIT then begins using the MIGB 
10 only 155. At decision point 156, the process 150 either continues or ends. If the process 
150 continues, the MIT may determine that it now requires its GBM 1 57. The MIT sends 
a message that it now requires its GBM 158 (e.g., to the CBM, which in turn informs the 
scheduler), and the MIT begins using the MIGB and the GBM with the scheduler 159. At 
decision point 1510, the process 150 either ends or returns to element 153, 
1 5 Turning to FIG 1 6, shown therein is an exemplary embodiment 1 60 of the 

interaction of the LIT with the various other tasks of FIGs 12-15. The LIT is informed by 
the allocation mechanism of the UGB and the CGBM 161. The LIT begins using the 
LIGB with the scheduler 162. At some point the LIT may be informed (eg., by the 
CBM) that the CGBM is available 163. The LIT then begins using the LIGB and the 
20 CGBM 164. At decision point 165, the process 160 either continues or ends. If die 

process 160 continues, the LIT may be informed (e.g., by the CBM) that the CGBM is no 
longer available 166. The LIT then begins using only the LIGB with the scheduler 167. 
At decision point 168, the process 160 either ends or returns to element 163. 
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Turning to FIG 17, shown therein is an exemplary embodiment 170 of the 
interaction of the various processes of FIGs 1-16 according to another aspect of the 
present invention. An application manager 171 assigns and de-assigns the MIT role to a 
given task (elements 1 1 and 14 of FIG 1). The application manager also assigns and de- 

5 assigns the LIT role to another given task (elements 12 and 15). The application manager 
171 then becomes inactive while the allocation mechanism 172 becomes active (element 
13 of FIG 1). When the MIT and LIT roles expire (element 57 of FIG 5), the application 
manager 171 becomes active again, while the allocation mechanism 172 becomes 
inactive. The allocation mechanism 172 allocates the MIGB and the GBM to the MTT 

10 . (element 121) and explicitly informs the MIT of these allocations (element 123). The 
allocation mechanism 172 also allocates the LIGB and the CGBM to the LIT (element 
123) and explicitly informs the LIT of these allocations (element 124). The allocation 
mechanism 172 sends the reservation to the CBM 176 (element 125), which executes 
process 130 of FIG 13. The CBM sends the reservation to the scheduler process 140 of 

15 FIG 14 (element 132), which executes to completion. The CBM receives messages from 
the MIT that the MIT no longer requires the GBM (element 134) and messages from the 
MIT that the MIT now requires the GBM (element 1 3 10). In turn, the CBM sends 
messages, respectively, to the LIT that the CGBM is available (element 137) and that the 
CGBM is no longer available (element 1311). In addition, the CBM sends reservation 

20 changes to the scheduler (elements 142) and receives acknowledgements (element 143) 
from the scheduler. The scheduler 173 accepts reservation commands for the LIT and the 
MIT from the CBM (element 121), grants the MIGB and GBM to the MIT and also 
grants the LIGB to the LIT (element 142). The scheduler then runs in accordance with a 
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scheduling algorithm (element 143). Changes in the reservations are sent by the 
scheduler 173 to the LIT and MIT (element 142). Acknowledgements of these changes 
are sent by the scheduler 173 to the sender (element 143). 

Turning to FIG 18, shown therein is a time flow of an exemplary embodiment 180 
5 of a method for controlling multiple processes according to yet another aspect of the 
present invention. The exact order of the processes set forth in FIG 1 8 is not significant, 
however, the order in time is important relative to some processes, which will be 
indicated when discussing these processes. Where not so indicated, the relative order 
could be varied. Upon start 181, the following process can occur for a two-process 
10 system. A similar process would occur for a three-process system, in which case the 
interaction would be similar between any two processes in the hierarchy. 

First, the relative priorities must be established. The allocation mechanism or 
some other process assigns the levels of priorities to the two tasks. One of these tasks is 
assigned to be the More Important Task 1 82, in which case the allocation mechanism may 
1 5 inform this process of its priority designation. The other of these tasks is assigned to be 
the Less Important Task 184, in which case the allocation mechanism may inform this 
process of its priority designation. The order in which the tasks are assigned priorities is 
not necessarily important For example, the lower priority task could be assigned first, 
hence element 1 84 could occur prior to element 182. 
20 Once the priorities are assigned, each of the tasks is explicitly informed of its 

budget. For example, the allocation mechanism explicitly informs the MIT about the 
More Important Guaranteed Budget and the Guaranteed Budget Margin 183. The 
allocation mechanism also explicitly informs the LIT about the Less Important 
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Guaranteed Budget 185 and the Conditionally! Guaranteed Budget Margin. The order of 
processes 1 83 tod 1 85 is not important other than each of them must occur after 
assignment of the relative priorities. Moreover, the informing of MIT budgets can occur 
immediately after the assignment of the MIT or after all priorities have been assigned. 
5 The informing of the LIT budget can occur before or after the informing of the MIT 
budget The only requirement is that the informing of the budgets can only occur after 
assignment of the relative priorities. 

After informing the MIT about its budget, the scheduler provides the More 
Important Guaranteed Budget plus the Guaranteed Budget Margin to the MIT at the first 
10 possible occasion 186. This provisioning of the MTT budget can occur before or after the 
informing the LIT about the Less Important Guaranteed Budget, and might even occur as 
early as immediately following assignment of the relative priorities to enable the MIT to 
begin using the MIT budget upon being so informed. 

Subsequent to provisioning the MIT budget, the scheduler provides the Less 
1 5 Important Guaranteed Budget to the LIT at the first possible occasion 1 87. This will 
normally occur after the provisioning of the MIT budget due to the relative priorities of 
the two tasks, but could occur as early as following assignment of the relative priorities to 
enable the LIT to begin using the LIT budget upon being so informed. 

At some point during execution, the MIT may observes that it can do its job with 
20 its More Important Guaranteed Budget only, in which case the MIT informs the scheduler 
of this observation 188. This can only occur after provisioning of the MIT budgets, but 
could occur at any point thereafter in the budget period. For simplicity purposes, the 
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observation and the informing of the scheduler are shown as a single element, but they 
could be separated in time. 

Once informed about the MIT's observation, the scheduler stops providing the 
Guaranteed Budget Margin to the MIT at the first possible occasion 189. This most likely 
* 5 will occur immediately following receipt of the information by the scheduler to enable 
use of the Guaranteed Budget Margin as early as possible. Once this condition (i.e., that 
the MIT does not require the Guaranteed Budget Margin) is determined to exist by the 
MIT, the system should make use of the Guaranteed Budget Margin as quickly as 
possible because this condition may not exist forever (or at least for the remainder of the 
10 budget period). 

Subsequent to stopping providing the Guaranteed Budget Margin to the MTT 189, 
the scheduler starts providing the Conditionally Guaranteed Budget Margin to the LIT at 
the first possible occasion 190. The scheduler then informs the LIT of this additional 
budget provision 191. Preferably this informing 191 should occur after provisioning of 
1 5 the Conditionally Guaranteed Budget Margin 1 90 so that the UT can begin using the 

extra budget without delay, however, in some situations these two elements 190, 191 may 
occur in different order. 

At some point during execution in the same budget period, the MIT may observes 
that it now requires its Guaranteed Budget Margin as well 192. This can occur at any 
20 time after element 188, and depending when thereafter some of the elements (i.e., 1 89, 
190 and 191) may be affected. After this new determination, the MIT explicitly informs 
the scheduler that it does require its Guaranteed Budget Margin 1 92. As before, these 
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two sub-steps may occur separated in time, however for simplicity purposes they are 
shown as a single element. 

After receiving this information, the scheduler informs the LIT that Conditionally 
Guaranteed Budget Margin will be withdrawn 193. Typically, this should occur before 
5 the scheduler stops providing this budget margin to the LIT to prevent improper use of 
resources and to enable the LIT to adjust accordingly and enable a smooth transition. 

The scheduler then stops providing the Conditionally Guaranteed Budget Margin 
* to the LIT at the first possible occasion 194. The scheduler then starts providing the 
Guaranteed Budget Margin to the MIT at the first possible occasion 1 95. The scheduler 
10 should first stop providing the extra budget to the LIT before providing the MET with the 
extra budget to prevent improper use of resources and to enable a smooth transition. 

At some point in time, the process ends 196; however, several other iterations of 
the elements 188-195 could occur depending upon application specifics. Moreover, the 
MIT may never determine it does not need the Guaranteed Budget Margin 1 88, or the 
1 5 MIT may never determine it needs the Guaranteed Budget Margin 1 92 after determining 
it does not need the Guaranteed Budget Margin 188. 

1 . Between an explicit grant and an explicit withdrawal of the Conditionally 
Guaranteed Budget Margin, the LIT can really count on the CSBM. Without the present 
invention, an LIT can never really count on its Conditionally Guaranteed Budget Margin. 
20 2. There is no need for a separate entity that detects the structural load increase, 

because a local control algorithm within the MIT application performs this detection as a 
by-product of its normal activity. 
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3. The local algorithm in the MIT can detect the structural load changes faster 
than a separate entity could, because it has a semantic interpretation for the resource 
usage measures. 

4. Since the LIT is explicitly informed about the availability of Conditionally 
5 Guaranteed Budget Margin, the LIT can react faster and more smoothly to the change. 

This advantage is a direct consequence of the Modified Budget Allocation Protocol (step 
(b)) discussed earlier. 

5. The MIT does not need to know the identity of the LIT; the MIT does not even 
need to know that there is an LIT. 

1 0 The main advantage of the basic process (as described in FIGs 1 -5) remains valid. 

The allocation mechanism is not involved in a budget transfer. This strongly reduces the 
overhead. As an example, there is no need for an admission test for the new situation, or 
a negotiation phase to determine the new quality level at which the various entities are 
running. 

15 In case of a synchronous MIT, it is possible to achieve several of the advantages 

with a degenerated version of Modified Budget Allocation Protocol (step (b)) discussed 
earlier. 

According to yet another aspect of the present invention, an exemplary 
embodiment of a computer readable media has encoded thereon programming 
20 instructions that control a processor to perform the above-mentioned processes and 

methods. For example, the processor is caused to perform the methods set forth in FIGs 
1-18. Examples of computer readable media include without limitation CD-ROMs, 
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DVDs, magnetic memory storage, RAM, ROM, hard drives, memory sticks, optical 
memory, etc. 

The use of the present invention can be traced because it requires explicit 
additional interfaces. 
5 Additional MIT Interface: 

Setjbudgets(in MIGB_value: budgeMype; in GBM_value: budget_type);//called by AM 
Additional LIT Interface: 

Set_budgets(in LIGB_value: budgetjype; in CGBM_value: budget Jype);//called by AM 
CGBM^availableO^called by scheduler. 
10 CGBM_not_availableO; called by scheduler. 
Additional Scheduler Interface: 
GBM ^required (in tid, task id);//called by MIT. 
GBM_not_required(in tid, task id)//called by MTT. 

The above inventions are applicable to televisions, receivers, audio-video 
15 processors, digital processors, set-top boxes, and other consumer electronics. 

Although various embodiments are specifically illustrated and described herein, it 
will be appreciated that modifications and variations of the invention are covered by the 
above teachings and are within the purview of the appended claims without departing 
from the spirit and intended scope of the invention. For example, certain terms and 
20 protocols are employed, however, other names and protocols could be used without 

departing from the scope of the present invention. Furthermore, this example should not 
be interpreted to limit the modifications and variations of the invention that are covered 
by the claims but is merely illustrative of possible variations. 
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CLAIMS: 

1. A method (60) for controlling multiple tasks (1 14, 1 15; 174,175) comprising: 
assigning (61) a first task to be a More Important Task (1 14, 174); 
assigning (62) a second task to be a Less Important Task (1 1 5; 175); 
allocating (63) a Guaranteed Budget Margin to the More Important Task (1 14; 

174) along with a More Important Guaranteed Budget and explicitly informing the More 
Important Task of this allocation; 

allocating (64) a Less Important Guaranteed Budget to the Less Important Task 
(1 1 5; 175) and explicitly informing the Less Important Task about this allocation; 

sending (67) a message that the More Important Task (1 14; 174) no longer 
requires the Guaranteed Budget Margin; and 

allocating (68) a Conditionally Guaranteed Budget Margin to the Less Important 
Task (1 1 5; 175) and explicitly informing the Less Important Task of this allocation. 

2. The method according to claim 1, further comprising determining (66) that the 
More Important Task (1 14; 174) no longer requires the Guaranteed Budget Margin. 

3. A method (60; 90; 150) for operating a first task (114; 174), which first task 
(1 14; 174) has been assigned a higher level of priority than a second task (115; 175) 
comprising: 

determining (66; 69; 93; 97; 1 53; 157) whether the first task (1 14; 174) requires 
additional budget margin; and 
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sending a message that either the. additional budget margin is no longer required 
(67; 94; 154) or that the additional budget margin is now required (691; 98; 158). 

4, The method according to claim 3, further comprising allocating (68) a 
conditionally guaranteed budget margin automatically to the second task (115; 175) upon 
receiving the message that the first task (1 14; 174) no longer requires the additional 
budget margin. 

5. Amethod(70; 190) for controlling two or more tasks (11 4, 115; 174, 175) of a 
multi-task process comprising: 

explicitly informing (73; 183) a first task (1 14; 174) that is a more important task 
about a More Important Guaranteed Budget and a Guaranteed Budget Margin; 

explicitly informing (74; 184) a second task (115; 175) that is a less important task 
about a Less Important Guaranteed Budget and a Conditionally Guaranteed Budget 
Margin; 

providing (82; 186) the More Important Guaranteed Budget plus the Guaranteed 
Budget Margin to the first task (1 14; 174) at a first possible occasion; 

providing (82; 187) the Less Important Guaranteed Budget to the second task 
( 1 1 5; 1 75) at a first possible occasion; 

upon the first task (114; 174) determining (93; 188) at some point during 
execution that the first task (1 14; 174) can do its job with the More Important Guaranteed 
Budget only, explicitly informing (94; 188) a scheduler (113; 173) that the first task (114; 
174) does not require its Guaranteed Budget Margin. 
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6. The method according to claim 5, farther comprising: 

stopping (1 89) to provide the Guaranteed Budget Margin to the first task (114; 
174) at a first possible occasion. 

7. The method according to claim 6, farther comprising: 

starting (190) to provide the Conditionally Guaranteed Budget Margin to the 
second task (115; 175) at a first possible occasion. 

8. The method according to claim 7, farther comprising: 

informing (191) the second task (1 15; 175) of the providing the Conditionally 
Guaranteed Budget Margin. 

9. The method according to claim 7, further comprising: 

determining (192) by the first task (114; 174) at some point during execution that 
the first task (1 14; 174) requires the Guaranteed Budget Margin. 

10. The method according to claim 9, further comprising: 

explicitly informing (192) the scheduler (1 13; 173) that the first task (1 14; 174) 
does require its Guaranteed Budget Margin. 

11. The method according to claim 10, farther comprising: 
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informing (193) the second task (115; 175) that the Conditionally Guaranteed 
Budget Margin will be withdrawn, 

12. The method according to claim 11, further comprising: 

stopping (194) to provide the Conditionally Guaranteed Budget Margin to the 
second task (1 15; 175) at a first possible occasion. 

13. The method according to claim 11, further comprising: 

starting (195) to provide the Guaranteed Budget Margin to the first task (1 14; 174) 
at a first possible occasion. 

14. An apparatus (1 10) comprising: 

a first task (1 14) having a first priority level; 

a second task (1 1 5) having a second priority level lower than the first priority 

level; 

an allocation mechanism (1 12) to allocate budgets of resources, said allocation 
mechanism (1 12) explicitly informing the first (1 14) task about a More Important 
Guaranteed Budget and a Guaranteed Budget Margin and ex^icitly informing the second 
task (115) about a Less Important Guaranteed Budget and a Conditionally Guaranteed 
Budget Margin; and 

a scheduler (1 1 3) providing the budgeted amounts to the first and second tasks 
(1 14, 115), said scheduler (1 13) providing the More Important Guaranteed Budget plus 
the Guaranteed Budget Margin to the first task (1 14) at a first possible occasion and 
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providing the Less Important Guaranteed Budget to the second task (1 15) at a first 
possible occasion, wherein upon the first task (1 14) determining at some point during 
execution that the first task (1 14) can execute properly with the More Important 
Guaranteed Budget only, said first task (1 14) explicitly informing the scheduler (1 13) that 
the first task (1 14) does not require its Guaranteed Budget Margin. 

15. The apparatus according to claim 14, wherein the scheduler (113) stops 
providing the Guaranteed Budget Margin to the first task (1 14) at a first possible occasion 
and starts providing the Conditionally Guaranteed Budget Margin to the second task ^ 

. (1 1 5) at a first possible occasion. 

16. The apparatus according to claim 15, wherein the scheduler (1 13) informs the 
second task (115) of the providing the Conditionally Guaranteed Budget Margin. 

17. The apparatus according to claim 14, wherein the first task (1 14) determines 
at some point during execution that the first task requires the Guaranteed Budget Margin 
as well and the first task explicitly informs the scheduler (1 1 3) that the first task (114) 
does require its Guaranteed Budget Margin. 

18. The apparatus according to claim 17, wherein the scheduler (1 13) informs the 
second task (115) that the Conditionally Guaranteed Budget Margin will be withdrawn. 
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19. The apparatus according to claim 18, wherein the scheduler (1 13) stops 
providing the Conditionally Guaranteed Budget Margin to the second task (115) at a first 
possible occasion. 

20. The apparatus according to claim 19, wherein the scheduler (113) starts 
providing the Guaranteed Budget Margin to the first task (1 14) at a first possible 
occasion. 

21. An apparatus (170) comprising: . 

a first task (174) having a first priority level; 

a second task (175) having a second priority level lower than the first priority 

level; 

an allocation mechanism (172) to allocate budgets of resources, said first task 
being explicitly informed about a More Important Guaranteed Budget and a Guaranteed 
Budget Margin and said second task being explicitly informing about a Less Important 
Guaranteed Budget and a Conditionally Guaranteed Budget Margin; 

a conditional budget monitor (176) to monitor an availability of the Conditionally 
Guaranteed Budget Margin, said conditional budget monitor to receive a message that the 
More Important Task (174) no longer requires the Guaranteed Budget Margin, to receive 
a message that the More Important Task (174) now requires the Guaranteed Budget 
Margin, to receive budget allocations of the Guaranteed Budget Margin, the 
Conditionally Guaranteed Budget Margin, the More Important Guaranteed Budget and 
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the Less Important Guaranteed Budget from the allocation mechanism (172), and to send 
out a reservation command regarding the budget allocations; and 

a scheduler (173) providing the budgeted amounts to the first and second tasks 
(174, 175) based on the reservation command, said scheduler (173) providing the More 
Important Guaranteed Budget plus the Guaranteed Budget Margin to the first task (174) 
at a first possible occasion and providing the Less Important Guaranteed Budget to the 
second task (175) at a first possible occasion, wherein upon the first task (174) 
determining at some point during execution that the first task (174) can execute properly 
with the More Important Guaranteed Budget only, said conditional budget monitor (176) 
sending a reservation command to the scheduler (173) including only the More Important 
Guaranteed Budget for the first task (174) and including the Conditionally Guaranteed 
Budget Margin along with the Less Important Guaranteed Budget for the second task 
(175). 

22. The apparatus according to claim 21, wherein upon the first task determining 
that is now requires the Guaranteed Budget Margin, and communicating this to the 
conditional budget monitor, the conditional budget monitor (176) sending a reservation 
command to the scheduler (173) including the Guaranteed Budget Margin and the More 
Important Guaranteed Budget to the first task (174) and the Less Important Guaranteed 
Budget only to the second task (175). 
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23. The apparatus according to claim 21; wherein the conditional budget monitor 
(173) informs the second task (175) of the providing the Conditionally Guaranteed 
Budget Margin. 

24. The apparatus according to claim 22, wherein the conditional budget monitor 
(173) informs the second task (175) that the Conditionally Guaranteed Budget Margin 
will be withdrawn. 



US030451 



44 



ABSTRACT 

A method (60) for controlling multiple tasks in a real-time operating system (1 10, 
170) assigns priorities to two or more tasks (1 14, 115; 174, 175). A first task (1 14; 174) 
is assigned to be a More Important Task. A second task (1 1 5; 1 75) is assigned to be a 
Less Important Task. Each task is explicitly informed of its budget allocations. A 
Guaranteed Budget Margin is then allocated to the More Important Task along with a 
More Important Guaranteed Budget. A Less Important Guaranteed Budget is also 
allocated to the Less Important Task. At some point during execution, the higher priority 
or More Important Task (1 14; 174) may then determine that the More Important Task no 
longer requires the Guaranteed Budget Margin, in which case, a Conditionally 
Guaranteed Budget Margin is then allocated to the Less Important Task (115; 175). 
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